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METHOD AND DEVICE FOR RE-ROUTING A CONNECTION IN A CONNECTION IN A TELECOMMUNICATIONS 
NETWORK COMPRISING A PLURALITY OF NETWORK ELEMENTS 

Field of the invention 

This invention relates to re-routing of a connection which is routed 
via some key network elements holding context information about the con- 
5 nection. 

Background of the invention 

Telecommunication networks can be divided into circuit switched 
networks and packet switched networks. In circuit switched networks, the 
communication is allocated a circuit prior to the beginning of the transmis- 

10 sion. An example of a circuit allocated to users A and B is given in figure 1 
showing the allocated circuit that can only be used by these users. Informa- 
tion about the recipient of the sent information is readily included in the cir- 
cuit identity. The main disadvantage of this switching method is that the cir- 
cuit is reserved even though there is no information to be sent. 

15 In connectionless packet switched networks, the transmission me- 

dia is common to all users. The information is sent in packets, and all pack- 
ets contain information about their destination. There is no need to allocate 
transmission resources for the communication prior to the beginning of the 
transmission. No packets are transmitted if there is no information to be sent. 

20 Thus, the network capacity in not reserved in vain. Based on the information 
about the destination included in the packet, every network element routes 
the packet to the next network element. The possible routes for the packets 
sent by user A to user B are shown in figure 2. Basically, all the packets sent 
from terminal A to terminal B do not necessarily travel through the same 

25 route. 

In connection oriented packet switched techniques, a method of 
establishing virtual circuits is known. A virtual circuit comprises predeter- 
mined legs between network elements, and every packet in a connection is 
routed along the same route. Thus, the information is routed as in circuit 
30 switched networks shown in figure 1, but the communication capacity is not 
reserved (in vain) if there is nothing to be sent. Every packet includes infor- 
mation about its virtual circuit, and every network element holds context in- 
formation which tells where to route a packet with a known virtual circuit to 
and what identifiers to use on the next leg. An example of a technique utilis- 
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ing virtual circuits is the well known ATM (Asynchronous Transfer Mode) 
technology. 

It is also known that the methods of virtual circuit and connection- 
less packet switching with no virtual circuits can be combined. In such a 
5 method, there are some network elements via which all the packets are 
routed. An example of such a method is given in figure 3. In figure 3, a virtual 
circuit passing through network elements 12 and 22 is allocated between the 
sender A and network element 32. Network element 32 holds context infor- 
mation for the connection, and knows that the packets on that virtual circuit 

10 are destined to receiver B, which is connected to network element 53. Be- 
tween network elements 32 and52, a connectionless packet switched net- 
work is used, and packets from element 32 can be routed to element 52 
along different paths. Though, all the packets are routed through network 
elements 12, 22, 32 and 53, which thus compose a virtual circuit between 

15 terminals A and B. It is worth noting that A would not be able to establish a 
connection with B if e.g. network element 32 would not hold the necessary 
context information concerning the connection. That information is not held 
by e.g. network element 31. Therefore, all the data packets of the connection 
have to be routed via network element 32 as well as through elements A, 12, 

20 22, 53 and B, which are the key network elements of the connection. 

An example of a system utilising virtual circuits is the General 
Packet Radio Service GPRS being specified by ETSI (European Telecom- 
munications Standards Institute). The basic structure of the GPRS network is 
shown in figure 4. The elements shown are Serving GPRS Support Node 

25 (SGSN1, SGSN2), Gateway GPRS Support Node (GGSN1, GGSN2) and 
the BSS (Base Station Subsystem) consisting of a Base Station Controller 
(BSC1, BSC2) and many Base Transceiver Stations (BTS11, BTS12, 
BTS21, BTS22). Connections to other networks (not shown), such as Inter- 
net or an X.25 network, are made via the GGSN. Additionally, the network 

30 includes a Home Location Register (HLR) where e.g. information about the 
subscribed services is kept. 

Basically, when a mobile station MS is located in a cell, every 
packet destined to or sent by mobile station MS is transmitted through the 
same BTS, same BSC, same SGSN and same GGSN. The MS cannot es- 

35 tablish a connection to the GGSN if the used SGSN does not hold context 
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information for this MS. The mobile MS is located in cell CELL1 1 and com- 
municating with a BTS, BTS11, through the radio interface Urn. Between the 
BTS and the SGSN, a virtual circuit is established, and all the packets are 
transmitted along the same route. In the connectionless packet switched 
5 network using the Internet Protocol (IP) between the SGSN and the GGSN t 
the transmission of different packets may use different routes. 

The link between the mobile MS and the SGSN is uniquely identi- 
fied by routing area RA and the Temporary Logical Link Identity TLLI. Rout- 
ing area consists of one or several cells, and is used in the GPRS mobility 

10 management as location information for mobiles in a so-called standby state 
in which the mobile has no active connections. The TLLI identifies the con- 
nection unambiguously within one routing area. A mobile can have multiple 
simultaneous connections using different protocols, e.g. X.25 and IP. Con- 
nections using different protocols are discriminated using a Network Layer 

15 Service Access Point Identity NSAPI. 

The application layer in the MS sends the SNDCP layer a PDP 
PDU (Packet Data Protocol Packet Data Unit) which can be, e.g., an IP 
packet. In the SNDCP layer, the PDU is encapsulated in an SNDCP packet 
in the header of which the NSAPI is indicated, and the resulting SNDCP 

20 packet is sent to LLC layer. The link layer identity TLLI is included in the LLC 
header. The LLC frames are carried over the air interface Urn by the RLC 
(Radio Link Control) protocol and between the BSC and SGSN by the 
BSSGP (Base Station Subsystem GPRS Protocol). For downlink packets, 
the BSS checks the cell identity indicated in the BSSGP header, and routes 

25 the cells to the appropriate BTS. For the uplink packets, the BSC includes 
the BSSGP header the cell identity of the mobile MS based on the source 
BTS. 

Between SSGN and GGSN, the link is identified by the SGSN and 
GGSN addresses and tunnel identifier TID which identifies the connection in 
30 the GGSN and in the SGSN. On the link between the SGSN and the GGSN, 
the GTP (GPRS Tunnelling Protocol) is used. 

GPRS is a system where a kind of a virtual connection is used be- 
tween MS and GGSN. This connection consists of two separate links, the 
MS-SGSN link and the SGSN-GGSN link. The MS and the GGSN are not 
35 able to communicate with each other if they are not using an SGSN holding 
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the context information for this MS. Therefore, the SGSN in a key network 
element. 

Routing of packets in the GPRS network is presented in the signal- 
ling chart of figure 5. In the figure, routing of both mobile originated (MO) and 
5 mobile terminated (MT) packets is shown. The routing of MO packets is 
studied first. The MS sends the BSS a data packet containing the TLLI, 
NSAPI and the user data. On the link between MS and SGSN, the SNDCP 
(Subnetwork Dependent Convergence Protocol) protocol on LLC (Logical 
Link Control) protocol is used. In a simple implementation, one BSC is al- 

10 ways using the same SGSN, and therefore its function is to route the packets 
between many BTS's and one SGSN. In a more complicated implementa- 
tion, the BSC is connected to a plurality of SGSN's and its routing function is 
also using the TLLI. In such implementation the key network elements of the 
connection are the MS, the BTS, the BSC, the SGSN and the GGSN that all 

15 hold context information necessary to route the packets belonging to the 
connection. In the BSS this information is stored in a look-up table. An ex- 
ample of a possible look-up table is shown the following: 



source 


TLLI 


destination 


SGSN1 


11 


CELL11 


SGSN1 


12 


CELL12 


SGSN2 


21 


CELL11 


SGSN2 


22 


CELL12 


CELL11 


11 


SGSN1 


CELL1 1 


21 


SGSN2 


CELL12 


12 


SGSN1 


CELL12 


22 


SGSN2 



20 According to the look-up table above, e.g. packets with TLLI=1 1 re- 

ceived from SGSN1 are forwarded to BTS11 for transmission over the air 
interface Um in cell CELL11. 

Each SGSN holds context information about each mobile it han- 
dles. In GPRS, the context information can be divided into mobility manage- 

25 ment (MM) and the packet data protocol (PDP) context part. Basically, the 
mobility management part tells where the mobile is located and in which 
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state (idle, standby, ready) it is, and is common for all the different packet 
data services using different protocols. The packet data protocol part tells 
information specific for the service in question, and includes, e.g. routing in- 
formation and PDP (packet data protocol) address used. Based on the con- 
5 text information, the SGSN maps the identifications TLLI and NSAPI used in 
the link between the SGSN and the MS to GGSN address and tunnel identi- 
fier TID, which identifies the connection between the SGSN and the GGSN. 
The GGSN then sends the data packet PDP PDU (PDP=Packet Data Proto- 
col PDU= Protocol Data Unit) to the external packet data network. 

10 For mobile terminated packets, the GGSN receives a packet sent to 

the MS from the external Packet Data Network (PDN). The GGSN knows 
which SGSN handles the connections of the MS and the identifier TID which 
identifies the connection in the SGSN. The packet is sent to the SGSN han- 
dling the MS, and the SGSN derives from the TID the TLLI, the NSAPI, the 

15 routing area identification RAI and eventually if not readily the cell identity 
CELLID. Based on this, the SGSN can send the packet to the right BSS. 
Using the TLLI, routing area and cell identity, the BSS can transfer the 
packet to the right MS. NSAPI is needed in the MS in order to be able to dis- 
criminate between different packet data protocols. 

20 The problem of the above described routing method is its rigidity 

when a key network element in the connection has to be modified. In the 
case of GPRS, SGSN is the key network element in the connection between 
the MS and the GGSN. It is normally changed only if the MS moves to the 
coverage area of another SGSN, which is known as an inter-SGSN routing 

25 area update. A need for changing a key network element in the connection 
can arise for many other reasons, such as when a network element breaks 
down, a new network element is installed, when a network element has to be 
shut down for operation and maintenance reasons, or when the traffic load in 
a network element is too high. In prior art, the change of a key network ele- 

30 ment cannot be done without interrupting all the ongoing connections. 

In GPRS, to change the SGSN via which the traffic from and to a 
routing area is routed, the network must be reconfigured and all the connec- 
tions from mobiles in that routing area to the gateway GPRS support nodes 
GGSN must re-established. In practice the MS's have to reattach to GPRS 

35 and reactivate their PDP contexts. This causes unnecessary load in all net- 
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work elements and in the transmission network, especially in the limited 
communication bandwidth on the radio interface Urn. 

The objective of this invention is to solve or at least relieve these 
problems. This objective is achieved by using a solution according to the in- 
5 vention which is defined in claim 1 . 

Summary of the invention 

The basic idea of the invention is to change a key network element 
in a connection without interrupting the traffic. 

In the re-routing procedure according to the invention, instead of 

10 cancelling existing connections and establishing a new one, the context in- 
formation is modified only in those network elements which the change in 
routing concerns. All the necessary context information about the existing 
connections has to be loaded to the new key network element introduced 
into the connection. Additionally, other network elements handling the con- 

1 5 nection have to be informed that one of the network elements of the connec- 
tion has changed. 

The invention is advantageously realised in a inter-SGSN re-routing 
in a GPRS network. The procedure can be made transparent to the end sta- 
tions. In the procedure, SGSN context is preferably loaded to the new SGSN 

20 advantageously from the old SGSN. The BSS is advised to route the mobile 
originated packets to the new SGSN. The GGSN is informed about the new 
SGSN address needed when routing the mobile terminated packets. 

Brief description of the figures 

The invention is described more closely referring to the enclosed 
25 schematic Figures, of which 

Figure 1 shows a circuit switched connection, 
Figure 2 shows a packet switched connection, 

Figure 3 shows a connection with a combination of a virtual circuit and a 
30 connectionless packet switched part, 

Figure 4 shows the topology of the GPRS network, 

Figure 5 shows the routing of a packet in the GPRS network, 

Figure 6 shows a virtual connection in the GPRS network, 

Figure 7 shows a modified virtual connection in the GPRS network, 
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Figure 8 shows the flow of information in the re-routing procedure in one 

embodiment of the invention and 
Figure 9 shows the flow of information in the re-routing procedure in another 

embodiment of the invention. 

5 Detailed description of the invention 

The routing of packets from and to a mobile MS before and after 
the re-routing of the connection and the information updates necessary to 
carry out the re-routing are now explained with the help of figures 6 and 7. 

Figure 6 shows a connection between a mobile user and the host 

10 computer HOST which is connected to the Internet using the IP protocol. The 
IP address of HOST is 222.222.222.222. The mobile MS, whose IP address 
is 333.333.333.333, is using base station BTS11, which belongs to routing 
area RA1 (not shown). 

The MS sends the HOST an IP packet P1 via the GPRS network. 

15 The IP packet is first encapsulated in an SNDCP packet (i.e., a data packet 
according to the SNDCP protocol) and then in an LLC frame containing the 
TLLI identity TLLI1, which identifies the link between the SGSN and the MS 
unambiguously within the routing area, and the NSAPI identifier NSAP1 1, 
which specifies the protocol used. The LLC frame is then sent to BTS1 1 . 

20 BTS11 is connected to base station controller BSC1. All the pack- 

ets sent by the MS are routed via BSC1. When receiving the packet from a 
BTS, the BSC adds to the packet the cell identity CELLID1 1 of the cell cov- 
ered by the BTS. BSC1 holds information about the particular SGSN the 
packets shall be sent to. In this case, all the packets coming from RA1 are 

25 sent to SGSN 1. 

SGSN1 contains more specific context information about every 
connection it handles. It maintains information about the location of the mo- 
bile with the accuracy of one routing area (when the mobile is in standby 
state) or one cell (mobile in ready state). When receiving a LLC frame from 

30 the BSC, the SGSN identifies the mobile that has sent the packet. The iden- 
tification is based on the cell identity CELLID11 and TLLI information in- 
cluded in the packet. With the help of this information, the NSAPI identity in- 
cluded in the packet and the SGSN context information concerning the mo- 
bile, the SGSN decides that the user data packet included in the SNDCP- 

35 packet must be sent to GGSN2. The context information also contains the 
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TID identifier TID1, which identifies the link for this MS between SGSN1 and 
GGSN2. SGSN1 generates a GTP (GPRS Tunnelling Protocol) packet in- 
cluding the user data packet, the address of the GGSN2 and the TID, and 
sends it to GGSN2. 

5 When receiving the GTP packet, GGSN2 knows, based on the TID 

identity and the GGSN context information, which MS has sent the packet. 
GGSN2 then sends the IP packet P1 to the external packet data network. 

When replying, HOST is sends a (mobile terminated) packet P2 
destined to the IP address 333.333.333.333 of the MS. Based on the IP ad- 

10 dress of the MS, the IP packet is first routed to the GGSN2. Based on the 
GGSN context information, GGSN2 then knows that the address belongs to 
the MS, that the MS is handled by SGSN1 and that the connection between 
GGSN2 and MS is identified in the SGSN with identifier TID1. Based on this, 
GGSN2 sends SGSN2 a GTP packet including the IP packet P2 sent by 

1 5 HOST and the TID identity TID1 . 

In SGSN1, the TID identity of the GTP packet is used to derive the 
routing area RA1, the cell identity CELLID1 1, TLLI1 and NSAPI1 . If the cell 
identity of the cell where the mobile is located in is not readily known, the MS 
is paged in all the cells of the routing area. NSAPI1 and TLLI1 are included 

20 together with the user data in an LLC frame which is then sent to the MS 
through right BSC. The right BSC is derived from the cell identity CELLID1 1, 
which is indicated to the BSC in the header of the BSSGP protocol. The BSC 
forwards the frame to the MS via BTS11, and the MS decapsulates the IP 
packet from the LLC frame. 

25 At this point, the need to reduce the traffic load of SGSN1 is ob- 

served. The need may arise e.g. when an SGSN malfunction is observed 
and the SGSN has to be shut down for operation & maintenance reasons or 
when the traffic load in a network element is too high. Alternatively, if a new 
SGSN is installed, some of the traffic load previously handled by SGSN1 

30 may be moved to the new SGSN. 

The O&M makes a decision of how many connections (o.e. MS's) 
or routing areas are moved to be handled by another SGSN. To minimise the 
changes in the system, it is advantageous to move all the GPRS traffic from 
one or more routing areas. In our example, all the connections from routing 

35 area RA1 are moved to SGSN2. This example is valid also if the connections 
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of only a list of MS's from routing area RA1 are transferred to RA2. To 
achieve this, the SGSN context information relating to the MS's in RA1 must 
be loaded to the new SGSN, SGSN2. Additionally, the BSC must be in- 
formed that the packets from routing area RA1 shall from now on be sent to 
5 SGSN2. To be able to route the mobile terminated packets via the correct 
SGSN, the GGSN has to be informed about the new SGSN address 
(SGSN2). The TID identifier TID1 will remain the same. 

After the re-routing procedure, both mobile terminated and mobile 
oriented packets are routed via SGSN2. Routing of packets between MS and 

10 HOST after the re-routing procedure is shown in figure 7. 

Let us now follow the route of an IP packet P3 sent by the MS to 
the HOST. Compared to the functions performed before the re-routing pro- 
cedure, there are no changes in the functions of the mobile MS and the base 
station BTS11. The MS still sends LLC packets including the TLLI, the 

15 NSAPI and the user data. BSC1 adds, as before, the cell identity CELLID in 
the header of the BSSGP packet it constructs, but now sends the packet to 
the new SGSN SGSN2. The only change in the BSC function is thus the new 
SGSN address SGSN2, to which the packets are now sent 

SGSN2 receives the packet and, with the help of the loaded context 

20 information, maps the TLLI identity and the NSAPI to GGSN identity GGSN2 
and to the tunnel identity TID TID1. It then sends GGSN2 a GTP packet in- 
cluding the user data and the TID. 

GGSN2 uses, as before, the TID identifier of the GTP packet to 
identify the subscriber identity IMSI and the IP address 333.333.333.333 of 

25 the MS. Then, the IP packet P3 encapsulated in the GTP packet and con- 
taining the user data, the destination address 222.222.222.222 and the IP 
address 333.333.333.333 of the sender is sent to its destination, i.e. to 
HOST. For mobile oriented packets, the GGSN function is thus just the same 
as it was before the re-routing procedure. 

30 As HOST sends the MS a mobile terminated packet P4 using the IP 

address 333.333.333.333 of the mobile, the packet is, as before, first routed 
to GGSN2. GGSN2 now uses the IP address to identify the MS identity IMSI, 
the TID and the SGSN identity SGSN2 according to the changes in the 
GGSN context. The GGSN sends the SGSN SGSN2 a GTP packet contain- 

35 ing the received IP packet and TID identity TID1 . 



9S59468A2 I > 



WO 98/59468 PCT/FI98/00552 

10 



SGSN2 receives the GTP packet, and, according to the loaded 
SGSN context information, maps the TID identity TID1 to routing area RA1, 
to cell identity CELLID11, to TLLI1 and to NSAPI1. TLLI1, NSAPI1 and CEL- 
LID1 are is included together with the user data in an LLC frame which is 
5 then sent to the right BSC. 

The BSC receives the LLC frame and, based on the TLLI identity 
TLLI1 in the packet, forwards the packet to the MS via BTS1 1. Again, there 
are no changes in the functions of BTS11 and MS as compared to their 
functions before the re-routing procedure. 

10 The flow of information needed in the re-routing procedure can be 

handled in various ways. In one embodiment of the invention, the traffic load 
is moved to the new SGSN smoothly. The flow of information in this em- 
bodiment is illustrated in figure 8. In this example, the traffic from on routing 
area RA1 is transferred to a new SGSN, SGSN2, to be handled there. 

15 O&M informs SGSN1 and SGSN2 that traffic from routing area RA1 

previously handled by SGSN1 will be moved to be handled by SGSN2 by 
sending them a messages 11a and Mb, respectively. Then O&M informs the 
BSS is informed that all the mobile oriented (MO) traffic from RA1 shall be 
routed to SGSN2 by sending the BSS a message 12. From this point, the MO 

20 packets are routed through SGSN2. SGSN1 can, if needed, force the MSs to 
generate uplink packets by sending them a message, e.g. by paging them. 
The new SGSN receives from the MS MS1 a packet 13 coming from a cell of 
RA1 and using a local TLLI unknown to SGSN2. SGSN2 determines the old 
SGSN (SGSN1) based on the cell identity. The SGSN2 requests the context 

25 information concerning the MS from SGSN1 using e.g. the SGSNContex- 
tRequest -message 14 in a way similar to the inter-SGSN routing area up- 
date. 

Having received the requested context (message 1 5, SGSNCon- 
textResponse), SGSN2 may perform security functions like authentication 

30 and allocation of a new TLLI. SGSN2 informs the relevant GGSN(s) about 
the new SGSN address to be used to forward packets to MS1 using the Up- 
date PDP Context Request procedure 16. Having done this SGSN2 initiates 
an update location procedure by sending message 17 toward the HLR. As a 
response to message 17 the HLR send the subscriber data of the MS's in 

35 RA1 to SGSN2 in message 18. If needed, it will also perform the Location 
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Updating procedure toward MSCA/LR. Additionally, the HLR sends a Cancel 
Location message 19 to the old SGSN SGSN1 to inform SGSN1 that it can 
now delete its context information concerning MS1. This is preferably done 
after a certain delay because some data packets may still be on their way 
5 from the GGSN to the old SGSN. The MS must also be informed about the 
new TLLI (if allocated). The old SGSN can now start forwarding data packets 
110 stored in the old SGSN, and not yet acknowledged by MS1 to the new 
SGSN. The packets may be associated with an indication about when they 
we sent so that SGSN2 knows when the possible retransmission should be 
10 performed. 

It is worth noting that messages from 14 to 110 are very much similar 
to messages used in InterSGSN Routing Area Update procedure and that 
their order can be changed. Therefore, the implementation of this invention 
requires no major changes in the network. 

15 When the traffic is handled by SGSN2, SGSN2 informs the O&M in 

message 11 1 that the connections are now re-routed. The virtual circuits from 
SGSN1 to the cells of the routing area can be cancelled. The O&M can 
eventually send messages 112a and 112b commanding SGSN1 and the BSS 
to cancel the virtual circuits. Additionally, the neighbouring GPRS support 

20 nodes must be informed that the routing area is now handled by a new 
SGSN, SGSN2. This can be done e.g. via O&M. This is, however, not nec- 
essary if the SGSN address can be derived from TLLI coding. 

In another embodiment of the invention, the SGSN context infor- 
mation is moved to the new SGSN before the actual change of SGSN. The 

25 flow of information is described in figure 9. The procedure of changing the 
SGSN serving a routing area is started by the O&M by informing SGSN1 and 
SGSN2 about the re-routing. This can be done e.g. by sending SGSN2 a 
message J1. As a response to J1, SGSN2 queries the context information 
from SGSN1 by sending message J2. SGSN1 provides the queried informa- 

30 tion in message J3, which advantageously includes context of all the con- 
nections that are to be moved to be handled by SGSN2 in a single message. 
SGSN2 saves the information to a sleeping database, and at this point, all 
the traffic goes through SGSN1 just as before. SGSN1 forwards all the 
changes in the SGSN contexts regarding those mobiles (and their connec- 

35 tions) that are being moved to SGSN2 in order to keep the sleeping data- 
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base up-to-date. In an alternative embodiment, the changes in the SGSN 
context are stored locally in SGSN 1 until they are explicitly requested by 
SGSN2. This embodiment minimises the signalling needed. 

When the sleeping database contains all the SGSN context infor- 
5 mation regarding those mobiles that are about to be moved to be handled by 
SGSN2, the actual re-routing can take place. Firstly, the virtual connection 
between the BSS and SGSN2 must be established. This is done by sending 
the BSS message J5, which gives the BSS the necessary information it need 
for modification of its routing table. Secondly, the GGSN(s) is (are) sent a 

10 PDPContextRequest message J6, which informs the GGSN about the list of 
MS's for which the SGSN address has to be changed. In an alternative em- 
bodiment, this information can be stored in the GGSN temporarily in a 
sleeping database. Thirdly, the HLR is sent a message UpdateLocation J7, 
which informs the HLR of the new SGSN address of the mobiles in the rout- 

15 ing area. The messages J6 and J7 are acknowledged (not shown). At this 
point, SGSN2 can inform the O&M that all the network elements hold the 
necessary context information (message J8). 

The O&M sends the BSS a message J9, which tells the BSS to 
start routing the frames coming from a given list of MS's to SGSN2. Similarly, 

20 the SGSN1 is sent a message J10, which tells that the context information 
for the mobiles that were moved to be handled by SGSN2 can now be de- 
leted after eventually having sent the latest update. 

For both previous embodiments the new SGSN SGSN2 can either 
re-establish the LLC link (as done in a normal inter-SGSN routing update) or 

25 maintain the link despite of the change. If the LLC link is re-established, 
SGSN2 needs to inform the MS. This can be done e.g. by performing an 
authentication procedure or by sending an explicit message (similar to the 
Routing Area Update Accept -message) containing the TLLI, PLMN (Public 
Land Mobile Network), supported mobile terminal capabilities, LLC acknow- 

30 ledgement and cause parameter. The MS shall answer by a message con- 
taining TLLI and LLC acknowledgement 

If the LLC link is maintained, some additional information must be 
included in the message 15 or J3 sent from SGSN1 to SGSN2. This informa- 
tion is: 
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- the cell identity of the ceil where the MS is currently located to 
allow SGSN2 to send the unacknowledged packets directly to 
BSS (if the service does not require the order of packets to be 
maintained) 

5 - information about ciphering 

- information about compression 

- information about the frames acknowledged if acknowledged 
transfer is used. 

The traffic from and to a single routing area RA1 may in some 

10 situations be handled by two different SGSN's. During the procedure, it may 
happen that a mobile MS2 in routing area RA1 that is being moved to be 
handled by SGSN2 is moving to another routing area RA2 handled by a third 
SGSN SGSN3. In this case, SGSN3 derives based on the old routing area 
RA1 the address of the SGSN that holds the context information of the mo- 

15 bile. This can be done based on an internal table in SGSN3 or optionally 
from a domain name server (DNS). If it finds out that RA1 is handled by 
SGSN1 it requests for the context information from SGSN1 which is, how- 
ever, no longer in charge of the mobile in question and has therefore not all 
the needed information. In this case SGSN1 can forward the request to 

20 SGSN2 now handling the mobile. SGSN2 may reply the request directly to 
the SGSN3 or via SGSN1. 

Alternatively, if SGSN1 can send SGSN3 a failure message. As a 
response to receiving the failure message SGSN3 asks for the IMSI of the 
mobile, and interrogates the HLR with the IMSI key. As a response, the HLR 

25 returns the new SGSN address SGSN2 of the mobile. 

Yet another possible solution is include the TLLI coding a digital 
signature which allows any other SGSN to find out which SGSN has allo- 
cated a given TLLI. The benefit of this embodiment is that the SGSN does 
not have to check the old routing area. On the other hand, the reallocation of 

30 TLLI is compulsory. 

Another problem caused by the situation of two SGSN's handling a 
single routing area is that a single TLLI should not be allocated twice within a 
single routing area. It must be noted that the probability of a double alloca- 
tion is low. Therefore, the situation of a double allocated TLLI can at least in 

35 some cases be handled by defining it as an error state which leads to re- 
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allocation of TLLI's for both the MS's sharing the same TLLI. The problem 
can as well be solved e.g. by including the TLLI coding a time stamp. In this 
case, the TLLI would comprise two parts, the code allocated by the SGSN 
and the time of allocation. A single TLLI would be double allocated only if two 
5 SGSN's would allocate the same code simultaneously. Another possible so- 
lution is to include the TLLI an identifier identifying the SGSN that allocated 
the TLLI. The identifier can be reused e.g. every eighth SGSN, thus reducing 
the number of bits needed to code the identifier to three. 

In the re-routing procedure, a various number of connections can 

10 be re-routed. Referring to GPRS, the re-routing can be done e.g. for one 
connection or a plurality of connections of one MS. In this case, however, the 
BSS should also need to examine the TLLI and eventually also the NSAPI 
identity of all the packets to be able to route the packets to the right SGSN. 
Another possibility is to re-route the connections from or to a single mobile or 

15 a plurality of mobiles within one routing area. In this case, care must be 
taken to handle the mobility management in a situation where traffic from 
one routing area is handled by two or more SGSN's. A third alternative is to 
re-route all the traffic from and to one routing area, a plurality of routing ar- 
eas or all the traffic handled by one SGSN. In these latter situations, no 

20 confusion can occur due to situations where several SGSN's are handling 
traffic from and to a single routing area. 

The use of the invention is not limited to the above described case 
where the connections are handed over from one SGSN to another, but the 
invention can be implemented to any network comprising similar key network 

25 elements. As an example, the GGSN can be changed during a connection in 
a similar way. 

The invention improves the network reliability by making the re- 
routing of connections more feasible. Thus, a lower reliability of an individual 
network element can be accepted, and the amount of duplication of modules 

30 in the network elements reduced. Further, network elements with lower traffic 
capacity can be used, because the possible local overload can be distributed 
to other network elements in the neighbourhood. Further, the operation and 
maintenance operations are easier to realise. These aspects have an im- 
portant impact on the costs of the network elements, and, as a clear conse- 

35 quence, on the cost of the whole network. 
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Claims 

1. A method for re-routing a connection in a telecommunications 
network comprising a plurality of network elements, the connection being 
routed through several network elements, at least two of those network ele- 

5 ments being key network elements of the connection, each key network ele- 
ment holding context information about the connection, said information in- 
cluding address of at least one other key network element of the connection, 
characterised in that 

a need to replace any of said key network elements (SGSN1) on 
10 the connection by another network element (SGSN2) capable of replacing 
said key network element is monitored, and, as a response to observing the 
need: 

the necessary context information is loaded to said another network 
element (SGSN2), and 
15 the address of the key network element (SGSN1) to be replaced is 

replaced by the address of said another network element (SGSN2) in the 
context information stored in other key network elements (GGSN2, BSC1) of 
the connection. 

2. A method according to claim 1, characterised in that 
20 the telecommunications network is a packet switched telecommunications 

network. 

3. A method according to claim ^characterised in that 
the telecommunications network is a mobile telecommunications 

network comprising mobile stations, base stations and cells defined by the 
25 coverage areas of the base stations and 

the re-routing method is triggered independent of the movement of 
the mobile stations. 

4. A method according to claim 3 for implementing re-routing in a 
GPRS network comprising a base station subsystem (BSC1, BTS11, 

30 BTS12), at least two serving GPRS support nodes (SGSN1, SGSN2) and a 
gateway GPRS support node (GGSN2), characterised in that in the 
re-routing procedure, a serving GPRS support node (SGSN1) used by the 
connection is replaced by another serving GPRS support node (SGSN2). 
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5. A method according to claim 1 or 3, characterised in 
that the re-routing procedure is triggered by the operation and maintenance 
system (O&M) of the network. 

6. A method according to claim 3 for implementing re-routing in a 
5 GPRS network comprising a base station subsystem (BSS), at least two 

network nodes that can act as serving GPRS support nodes (SGSN1, 
SGSN2) and at least one gateway GPRS support node (GGSN), char- 
acterised in that 

the operation and maintenance system (O&M) informs the BSS to 
10 change the serving GPRS support node to which it routes the packets be- 
longing to a certain connection from a first serving GPRS support node 
(SGSN1) to a second serving GPRS support node (SGSN2), 

as a response to receiving a packet belonging to the connection, 
the second serving GPRS support node (SGSN2) 
15 - loads the context information concerning the connection 

from the first serving GPRS support node (SGSN1), 

- informs the GGSN about the new SGSN and the identifier 
identifying the connection in the second SGSN. 

7. A method according to claim 3 for implementing a re-routing in a 
20 GPRS network comprising a base station subsystem (BSS), at least two 

network nodes that can act as serving GPRS support nodes (SGSN1, 
SGSN2 and at least one gateway GPRS support node (GGSN), char- 
acterised in that 

as a response to detecting a need to transfer a connection from a 

25 first serving GPRS support node (SGSN1) to a second serving GPRS sup- 
port node (SGSN2), the operation and maintenance system tells the second 
serving GPRS support node (SGSN2) to start downloading the SGSN con- 
text information concerning the connections from the first serving GPRS 
support node (SGSN1), 

30 the second serving GPRS support node (SGSN2) downloads the 

information into a sleeping database, 

the BSS is informed about the new SGSN used in the connection, 

and 

the GGSN is informed about the new SGSN used in the connection 
35 and the identifier identifying the connection in the second SGSN. 
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8. A method according to claim 7, characterised in that 
the sleeping database is kept up-to-date by the first serving GPRS support 
node (SGSN1). 

9. A method according to claim ^characterised in that as 
5 a response to receiving at a first network element a request for information 

concerning the connection that has been re-routed by replacing the first net- 
work element of the connection by another network element, the request is 
forwarded to said another network element now handling the connection. 

10. A telecommunications network comprising a plurality of network 
10 elements, said network comprising 

means for establishing virtual connections between users and 
several network elements, each network element holding context 
information about connections passing through that particular network ele- 
ment, said information including addresses of at least one other network 
15 element used by the connection, 

characterised in that the network further comprises 
monitoring means for monitoring a need to replace a first network 
element (SGSN1) on the connection by a second network element (SGSN2), 
triggering means responsible to the monitoring means for triggering 
20 the re-routing procedure, 

means for loading context information from the first network ele- 
ment (SGSN1) to the second network element (SGSN2) and 

means for replacing the address of the first network element 
(SGSN1) by the address of the second network element (SGSN2) in the 
25 context information stored in other network elements (GGSN2) of the con- 
nection. 

1 1 . A network according to claim 10, characterised in that 
the network is a packet switched telecommunications network. 

12. A network according to claim 10, characterised in that 
30 the network is a mobile telecommunications network. 

13. A network according to claim 12, characterised in that 
the network is a GPRS network. 

14. A network element for a packet switched telecommunication 
network, the network element having context information about at least some 

35 of the connections passing through that particular network element, 
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characterised in that, 

the network element comprises means for maintaining a sleeping 
database and is adapted to download context information from another net- 
work element into the sleeping database as a response to receiving a mes- 
5 sage triggering a re-routing procedure and 

the network element is adapted to allow the sleeping database to 
be dynamically updated by another network element. 

15. A network element for a packet switched telecommunication 
network, the network element having context information about at least some 
10 of the connections passing through that particular network element, 

characterised in that, 

the network element comprises means for maintaining a sleeping 
database and is adapted to download context information from another net- 
work element into the sleeping database as a response to receiving a mes- 
15 sage triggering a re-routing procedure and 

the network element is adapted to allow the sleeping database to 
be updated when requested. 
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